Size Change: -91 B (-0.01%)

Total Size: 1.77 MB

_{compressed-size-action}

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @skora-cpl, @MikeB8s, @sophiegyo.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: skora-cpl, MikeB8s, sophiegyo.

Co-authored-by: ockham <[email protected]>
Co-authored-by: skorasaurus <[email protected]>
Co-authored-by: justintadlock <[email protected]>
Co-authored-by: swissspidy <[email protected]>
Co-authored-by: joedolson <[email protected]>
Co-authored-by: celloexpressions <[email protected]>
Co-authored-by: Julianoe <[email protected]>
Co-authored-by: ms-studio <[email protected]>
Co-authored-by: ndiego <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Flaky tests detected in 1ba1c00.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10679375583
📝 Reported issues:

• [Flaky Test] Sorting #64430 in /test/e2e/specs/site-editor/new-templates-list.spec.js

Thank you very much for testing this, @skorasaurus!

From a functionality perspective, I noticed that when the showHierarchy attribute is marked as true and a variation for a taxonomy that does have a hierarchy (I believe that's controlled by hierarchical => false (as shown in https://gitlab.com/cpl/citation-manager/-/blob/72c2638d9827dea5d465be0db5d3ba41dfe3ae88/register-taxonomies.php#L47 & https://gitlab.com/cpl/citation-manager/-/blob/72c2638d9827dea5d465be0db5d3ba41dfe3ae88/register-taxonomies.php#L135); the list of terms did not display within the editor (and there was no message in the editor or the console) but the list of terms displayed on the frontend.

Ah right, I see what's going on here. Hierarchical terms are "category-like", whereas non-hierarchical ones ("flat terms") are tag-like.

The Categories List block (and underlying code, cf. wp_list_categories() and wp_dropdown_categories()) offer the "show hierarchical" option in order to render nested categories as such, e.g.

However, this option makes no sense for flat terms, since there is no hierarchy -- and thus, no nesting to be rendered. (The way it's implemented resulted in an empty list being rendered if that attribute was set for a non-hierarchical terms list block.)

I've pushed some code to conditionally remove that toggle (and the showOnlyTopLevel one) from the block inspector for flat terms, and added some logic to make sure that even if those attributes are already set on a given block (e.g. by transforming a Categories List block that had them set into a Tags List one), they'll be ignored.

Note to self: Add testing with flat terms (tags) to Testing Instructions 😅

I would prefer the route taken in #26555. A dropdown for the taxonomy would be more consistent with the existing Tag Cloud block (which is more similar to this block in functionality than Post Terms):

I've also seen where moving this sort of thing to variations creates issues for extenders who are creating their own variations. I'd need to test, but I'm wondering how this might play out when a user chooses a theme/plugin variation for this block but then wants to change the taxonomy. Tying the taxonomy setting to a set of variations doesn't feel like the best route.

Tying the taxonomy setting to a set of variations doesn't feel like the best route.

I see it the same. This settings feels more suitable for a dropdown, whereas the variation is more for changing the appearance.

#33302 asks for 1 universal Terms block, and that's what I think makes most sense. Not variations on the categories block.

I would even go as far and say the tag cloud block should be deprecated in favor of a tag cloud variation on this Terms blocks.

I agree with @swissspidy and @justintadlock in preferring a single Terms block with selection of the desired taxonomy. I think that having block variations be based on the data source rather than the appearance is confusing and unexpected.

Having a cloud presentation as a variant makes sense to me - that's a change that's more presentation oriented.

Thanks for weighing in, folks! Seems like there’s overwhelming sentiment against using variations.

I’m still somewhat concerned about the inconsistency with the Post Terms block. In day-to-day use of the Site Editor, I’d expect people to use those blocks much more alongside each other than e.g. the Tag Cloud block.

One other thing to note is that some of the toggles in the blog inspector are only displayed for hierarchical (i.e. category-like) taxonomies (but not for flat — tag-like — ones). This means that if the block is switched from a hierarchical taxonomy to a flat one, those toggles will disappear. I’d wager a guess that this might be slightly less confusing to the user if it’s coupled to transforming the block to a different variation (which might feel like a "bigger" change) than if coupled to a "simple" dropdown that might be perceived as kind of on the same level as the toggles, information architecture-wise.

—

Anyway, since #26555 is heavily outdated, I’ve spun up a branch (so far without PR) for a version of the block with a block inspector dropdown (and no variations). Here’s two screencasts to compare them:

Block Variations	Dropdown

I’ll also ask designers to weigh in. This is the kind of decision I’d like to run by at least one of them before we commit to either direction :)

I’ll also ask designers to weigh in. This is the kind of decision I’d like to run by at least one of them before we commit to either direction :)

I've only had some preliminary feedback via a private Slack channel so far, but that also favored the dropdown version over the block variations. As a consequence, I've now filed #65272 for that version. Please leave your reviews there when you have a moment! 😊

I've merged #65272 (i.e. the version without variations), and I'll thus close this PR.
I have however rebased it on trunk, in case we would ever like to revisit adding individual block variations. One reason for doing so could be UX flaws, e.g. the fact that as of #65272, the block no longer comes up first in the block inserter when typing categories; instead, users see a block called "Categories", which is simply the variation of the (unrelated) core/post-terms block.